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"The MAILING DATE of this communication appears on the cover sheet with the correspondence address - 



THE REPLY FILED 1 1 September 2008 FAILS TO PLACE THIS APPLICATION IN CONDITION FOR ALLOWANCE. 

1 . ^ The reply was filed after a final rejection, but prior to or on the same day as filing a Notice of Appeal. To avoid abandonment of this 

application, applicant must timely file one of the following replies: (1 ) an amendment, affidavit, or other evidence, which places the 
application in condition for allowance; (2) a Notice of Appeal (with appeal fee) in compliance with 37 CFR 41 .31 ; or (3) a Request 
for Continued Examination (RCE) in compliance with 37 CFR 1.114. The reply must be filed within one of the following time 
periods: 

a) Q The period for reply expires months from the mailing date of the final rejection. 

b) ^ The period for reply expires on: (1) the mailing date of this Advisory Action, or (2) the date set forth in the final rejection, whichever is later. In 

no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of the final rejection. 

Examiner Note: If box 1 is checked, check either box (a) or (b). ONLY CHECK BOX (b) WHEN THE FIRST REPLY WAS FILED WITHIN TWO 

MONTHS OF THE FINAL REJECTION. See MPEP 706.07(f). 
Extensions of time may be obtained under 37 CFR 1 .136(a). The date on which the petition under 37 CFR 1 .136(a) and the appropriate extension fee 
have been filed is the date for purposes of determining the period of extension and the corresponding amount of the fee. The appropriate extension fee 
under 37 CFR 1 .1 7(a) is calculated from: (1) the expiration date of the shortened statutory period for reply originally set in the final Office action; or (2) as 
set forth in (b) above, if checked. Any reply received by the Office later than three months after the mailing date of the final rejection, even if timely filed, 
may reduce any earned patent term adjustment. See 37 CFR 1 .704(b). 
NOTICE OF APPEAL 

2. □ The Notice of Appeal was filed on . A brief in compliance with 37 CFR 41 .37 must be filed within two months of the date of 

filing the Notice of Appeal (37 CFR 41 .37(a)), or any extension thereof (37 CFR 41 .37(e)), to avoid dismissal of the appeal. Since a 
Notice of Appeal has been filed, any reply must be filed within the time period set forth in 37 CFR 41.37(a). 
AMENDMENTS 

3. □ The proposed amendment(s) filed after a final rejection, but prior to the date of filing a brief, will not be entered because 

(a) n They raise new issues that would require further consideration and/or search (see NOTE below); 

(b) IIII They raise the issue of new matter (see NOTE below); 

(c) □ They are not deemed to place the application in better form for appeal by materially reducing or simplifying the issues for 

appeal; and/or 

(d) IIII They present additional claims without canceling a corresponding number of finally rejected claims. 

NOTE: . (See 37 CFR 1 .116 and 41.33(a)). 

4. □ The amendments are not in compliance with 37 CFR 1.121. See attached Notice of Non-Compliant Amendment (PTOL-324). 

5. O Applicant's reply has overcome the following rejection(s): . 

6. □ Newly proposed or amended claim(s) would be allowable if submitted in a separate, timely filed amendment canceling the 

non-allowable claim(s). 

7. □ For purposes of appeal, the proposed amendment(s): a) □ will not be entered, or b) □ will be entered and an explanation of 

how the new or amended claims would be rejected is provided below or appended. 
The status of the claim(s) is (or will be) as follows: 

Claim(s) allowed: . 

Claim(s) objected to: . 

Claim(s) rejected: . 

Claim(s) withdrawn from consideration: . 

AFFIDAVIT OR OTHER EVIDENCE 

8. □ The affidavit or other evidence filed after a final action, but before or on the date of filing a Notice of Appeal will not be entered 

because applicant failed to provide a showing of good and sufficient reasons why the affidavit or other evidence is necessary and 
was not earlier presented. See 37 CFR 1 .1 16(e). 

9. □ The affidavit or other evidence filed after the date of filing a Notice of Appeal, but prior to the date of filing a brief, will not be 

entered because the affidavit or other evidence failed to overcome all rejections under appeal and/or appellant fails to provide a 
showing a good and sufficient reasons why it is necessary and was not earlier presented. See 37 CFR 41 .33(d)(1 ). 

1 0. □ The affidavit or other evidence is entered. An explanation of the status of the claims after entry is below or attached. 
REQUEST FOR RECONSIDERATION/OTHER 

1 1 . ISI The request for reconsideration has been considered but does NOT place the application in condition for allowance because: 

See Continuation Sheet. 

12. □ Note the attached Information Disclosure Statement{s). (PTO/SB/08) Paper No(s). 

13. □ Other: . 

/William C. Vaughn, Jr./ 

Supervisory Patent Examiner, Art Unit 2144 
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Continuation of 1 1 . does NOT place the application in condition for allowance because: Jouppi discloses, In the method, at least one filter 
(filtering based IPv6 version address) is formed to guide mapping of at least one data flow of the first subsystem to at least one data flow of 
the second subsystem. At least one filter is attached to at least one data flow of the second subsystem. The filter comprises at least part of 
the interface identifier of the IP address, which at least part of the interface identifier is allocated in the wireless terminal device. Hereby, 
mapping of the data flow of the first subsystem to the data flow of the second subsystem is performed on the basis of the interface 
identifiers of the destination IP addresses in the received packets. GPRS services (General Packet Radio Service) and packet-switched 
services of the UMTS system (Universal Mobile Telecommunications System) utilize PDP (Packet Data Protocol) contexts in transmitting 
user data. PDP contexts are generally logical connections with which the IP data is transmitted from a mobile station to the gateway GPRS 
support node (GGSN) of the UMTS network, and vice versa. The mobile station knows which application data flows are to be directed into 
which PDP context tunnel in the transmission of uplink data. In the direction of the downlink, the gateway GPRS support node GGSN must 
also know packet-specifically which PDP context is used for which data flow received from an external IP network. For this purpose, the 
destination IP address of the packet is used, and also TFT (Traffic Flow Template) templates are defined for the UMTS. The idea of TFT 
templates is that the mobile station transmits given values of TCP/UDP/IP address fields to the gateway GPRS support node GGSN for the 
identification of the flow. The TFT contains one or more so called packet filters. The filter functionality can be implemented by using not only 
an interface identifier but also other predetermined parameters and/or conditions with which the packets or data flows can be identified. 
Interface identifier is a filter parameter of a TFT template used in the UMTS system. In such a case, the wireless terminal can activate the 
PDF context by using the interface identifier it has allocated. Since the wireless terminal in the GGSN network element operating as the 
edge node of the UMTS system is identified with the prefix of the IPv6 address when using IPv6 addresses, no prefix needs to be 
transferred in this case in messages relating to the activation of secondary PDP contexts, whereby the amount of information to be 
transmitted is smaller. On the basis of the requirements of the application, the MS determines for the PDP context request the quality of 
service QoS to be requested and for the TFT template the required filter information. On the basis of the request message, a new PDP 
context is negotiated 603 between the MS, SGSN and GGSN (or an existing PDP context is modified). At least the interface identifier is 
determined as the filter parameter of the PDP context TFT template (filter Fl) transmitted by the MS in question for the filter functionality FF 
of the gateway GPRS support node GGSN. When a new PDP context is active, the MS can concatenate an interface identifier for the IPv6 
prefix allocated to it and transmit 604 packets of the application plane APP, whereby the MS adds the interface identifier it has allocated as 
the suffix of the IP source address of the APP packets. The TFT is transmitted transparently through the SGSN. The TFT can comprise at 
least the following filter parameters: source IP address (refers to the address of a peer device in an external network PDN), source gate, 
destination gate, DiffServ field (Differentiated Services), flow identifier (IPv6), protocol number (IPv4)/ the next address field (IPv6), security 
parameter index SPI in connection with the IPSec protocol, and according to the present preferred embodiment also an interface ID 
allocated by one or more mobile stations. Examiner understanding of filtering and extracting is to be same as the functional objective is 
achieved by both in identifying parameters for IPv6 addresses of packets as an end result. 

As regards to Krishnarajah discloses, in a UMTS architecture, the UE identifies a flow based on a set of parameters defined in a traffic flow 
template (TFT) which acts as a packet filter using filter parameters, like IP source/destination address, UDP source/destination address, 
etc., that are the same for an IP stream. The TFT is mapped to a specific GTP tunnel for which the PDP context was initiated. In the case 
where an IPv6 the flow label is used for flow identification, the UE initiates one TFT per flow and then maps it to the GTP tunnel. Although 
the flow label identify in the IPv6 header has been described here, similar identifiers in an IP packet, including in an IPv4 packet, may be 
used to indicate the subflows of a particular CODEC stream in order to perform different treatment on those subflows, e.g., a TOS field in 
the IPv4 header could be redefined. The RTP header may have the format shown in FIG. 16A. The RTP header includes an extension 
mechanism to allow individual implementations to experiment with new payload format independent functions that require additional 
information to be carried in the RTP data packet header. The RTP header extension indicates the subflows/radio bearer, e.g.. Class A, B, 
and C. An RTP header extension is shown in FIG. 16B. If the X bit in the RTP header is a "1," a variable-length header extension is 
appended to the RTP header, following the contributing source (CSRC) identifiers list if present. The header extension contains a 16-bit 
length field that counts the number of 32-bit words in the extension, excluding the four-octet extension header (therefore zero is a valid 
length). A single extension may be appended to the RTP data header. To allow multiple interoperating implementations to each experiment 
independently with different header extensions, or to allow a particular implementation to experiment with more than one type of header 
extension, the first 16 bits of the header extension are left open for distinguishing identifiers or parameters. The format of these 16 bits is to 
be defined by the profile specification under which the implementations are operating. The radio protocol architecture for UTRAN is 
illustrated in FIG. 10 (refer to 3GPP TS 25.301 ). The left side of the protocol stack corresponding to the radio resource control (RRC) and 
below indicated as non-access stratum (NAS), represents the control plane (signaling). The right side of the protocol stack represents the 
user plane (user traffic). Referring to the user plane, an application layer rests on a transport layer which is serviced in this example by the 
real-time transport protocol (RTP), the RTP control protocol (RTSP), etc., which rests upon the traditional transport protocols, the 
transmission control protocol (TCP), and the user datagram protocol (UDP). The network layer is the Internet Protocol (P) layer which can 
be any version including IP version 4 and IP version 6. The packets generated at the IP layer are then mapped to radio bearers in the link 
layer corresponding to logical channels. Header compression of packets, described further below, may occur here. The radio link control 
and media access control (MAC) map the radio bearers onto transport channels provided to the physical layer which sends the packets 
over the radio interface. A radio bearer (RB) is a service that the UTRAN offers the radio access bearer (RAB). The relationship between 
RABs and RBs is illustrated in FIG. 11. The kernel shown between the application and the RABs is the operating system software. An RAB 
can be split into several parts or subflows, with each subflow associated with a different radio bearer. An RAB subflow is associated with a 
radio bearer, a QoS class or treatment, and a fragmented payload. The decision to have a radio access bearer with one or more subflows is 
made during quality of service negotiation. Each subflow may have different quality of service requirements/characteristics or treatment. 
The core network indicates, in the lu user plane frame protocol, a number and size of subflow to the RNC in the UTRAN. The RNC splits 
the lu user plane frame into various subflows and directs the traffic to the appropriate radio bearer. 
In view of the above disclosure, arguments presented are not persuasive. 



2 



Continuation Sheet (PTO-303) Application No. 10/781,865 



3 



